|
On 04 feb 2016, at 02:33, Alan Seiden <alan@xxxxxxxxxxxxxx> wrote:
Hi, Cassiano,
Now that you’ve increased parallelism by reducing session locking, have you checked how many PHP children are configured in fastcgi.conf? The default is 10 but you may need more.
Best regards,
Alan
--
Alan Seiden Consulting LLC
Project leader, Zend PHP Toolkit for IBM i
Zend Framework certified contributor
Office: 201-447-2437
http://www.alanseiden.com | alan@xxxxxxxxxxxxxx
http://twitter.com/alanseiden
On Feb 3, 2016, at 5:30 AM, c.vailati@xxxxxxxxxxxxxxx wrote:
Hi Alan,
thank you very much. I’ve fixed the web app as you suggested and did some tuning on the code execution.
The parallelization seems to work better. We have 6/7 concurrent execution running right now.
Given that we have lots of requests, I was wondering if is there something we can do to get even further on fastening the responses?
I know that a good chance would be having a Memcache session handler. The PHP module is actually installed by Zend Server, but I can’t find any documentation about installing a memcached server on IBMi.
Maybe it’s not possible, but do you have some experience on this subject?
Thanks again for the help.
Cassiano Vailati - ESC
Enterprise Software Consulting
Cassiano Vailati Canta
Software Architect
m: +39 346 0010240 | t: +39 0363 302050 | f: +39 0363 1901007
e: c.vailati@xxxxxxxxxxxxxxx <mailto:c.vailati@xxxxxxxxxxxxxxx> | w: esconsulting.it <http://www.esconsulting.it/>
ESC Enterprise Software Consulting
via Baslini, 7
24047 Treviglio (BG)
Italy
* * *
L'utilizzo non autorizzato del presente messaggio è vietato e potrebbe costituire reato.
Se il presente messaggio non e' a Lei indirizzato, Le saremmo grati se, via e-mail, ne comunicasse l'errata ricezione.
Il contenuto del presente messaggio non deve essere considerato come trasmesso o autorizzato da ESC Enterprise Software Consulting.
ESC Enterprise Software Consulting non si assume alcuna responsabilità per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
Notice: the information contained in this message is intended only for use of the individual(s) named above and may contain confidential, proprietary or legally privileged information.
No confidentiality or privilege is waived or lost by any mistransmission.
If you are not the intended recipient of this message you are hereby notified that you must not use, disseminate, copy it in any form or take any action in reliance of it.
If you have received this message in error please delete it and any copies of it and notify the sender immediately.
On 27 gen 2016, at 23:38, Alan Seiden <alan@xxxxxxxxxxxxxx> wrote:
Hi, Cassiano,
Every AJAX request coming from a single browser page will use the same PHP session. This session (really a temp file) is locked during the PHP request to ensure that the session is updated by one request at a time. This locking is the most likely cause of your problem. To resolve the issue, use session_write_close() after updating $_SESSION in your scripts.
Alan
--
Alan Seiden Consulting LLC
Project leader, Zend PHP Toolkit for IBM i
Zend Framework certified contributor
Office: 201-447-2437 Cell: 201-248-4704
http://www.alanseiden.com | alan@xxxxxxxxxxxxxx
http://twitter.com/alanseiden
On Jan 27, 2016, at 12:57 PM, c.vailati@xxxxxxxxxxxxxxx wrote:
Hello to everyone,
I’m experimenting some performance issues on an IBMi machine running PHP and I would like to ask if someone have some hints.
Some premises about the environment:
IBMi Power 8 with OS400 V7R2 on a IASP storage
Zend Server 8.5.1 with Z-Ray and many other services disabled, at the moment we just use the HTTP Apache service and the XMLTOOLKIT service.
We are running a PHP application which receives many concurrent ajax (asynchronous request) per user from the browser.
At this point we would expect that all the requests are handled in parallel processes.
But running the WRKACTJOB on the server produces just a few (one or sometimes two) actual working jobs as follows:
Subsystem User Type CPU Status
QSQSRVR ESCPHP PJ 2,1 RUN
We understood that the QSQSRVR Pre-start Job is the connection to the database and our application is structured to open one single new, non persistent, connection for each request.
It seems that our requests at this point are not handled concurrently, but re-using the same Pre-start Job even for different requests.
So the first Ajax requests give a fast and correct answer to the browser, but the last ones end up in a Timeout Request.
We already tried to do some tuning on the fastcgi.conf:
StartProcesses="1" => StartProcesses="2"
SetEnv="PHP_FCGI_CHILDREN=10" => SetEnv="PHP_FCGI_CHILDREN=40"
This operation opened more Apache/Zend Server sockets, but did not change the behavior of QSQSRVR
Subsystem User Type CPU Status
ZENDSVR6 QTMHHTTP BCI 0,0 PGM-php-cgi.bi TIMW
On a different server (a testing environment) we tried to enhance the number of Pre-start Job available for QSQSRVR using the following command and restarting the system, but we experienced the same issue:
ADDPJE SBSD(QSYSWRK/QSQSRVR) PGM(QSYS/QSQSRVR) STRJOBS(*YES) INLJOBS(50) THRESHOLD(40) ADLJOBS(20) MAXUSE(*NOMAX)
Is there some info that I’m missing or some other configuration that I could try?
Thank you in advance for your help
Have a nice evening
Cassiano Vailati - ESC
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
