Welcome Guest, Not a member yet? Register   Sign In
Performance Problem [solved]
#11

(08-17-2017, 08:51 AM)Narf Wrote:
(08-17-2017, 07:22 AM)bitwiz Wrote: PHP usually calls session_write_close() automatically after code execution (and I was used to that happening), I read on the forum someone asked if it was okay to place it in __destruct() and the response was no and I didn't understand their reasoning, sorry I don't remember where I read that.

__destruct() will rarely be called when you need it, and is kind of unpredictable at times.

(08-17-2017, 07:22 AM)bitwiz Wrote: If I want to simulate PHP's call on script completion where would I place session_write_close() or is there a way to turn that automation back on?

Is that this variable? $config['sess_regenerate_destroy'] = FALSE;

No, sess_regenerate_destroy has nothing to do with it and it's already automated - PHP will close the session itself. Point of calling session_write_close() yourself is that you know it will be beneficial to do it at a certain execution point, there's no way to automate that.

Thank you for the clarification.
Reply
#12

I guess I'll step through the code piece by piece and turn various things on and off. I'm getting the impression there's no good way to determine or narrow down the issue at this point.
Reply
#13

These two attachments are from 2 page refreshes, seconds apart. Does this indicate anything?

Attached Files Thumbnail(s)
       
Reply
#14

No, no kind of screenshot can indicate anything, just as your hardware doesn't really matter ... you're looking this from the wrong angle.

There's something blocking concurrent requests (if there are such) or time-outing (often a DNS lookup). Unless you're calling some other external service, I'd look at the DB config.
Reply
#15

(This post was last modified: 08-17-2017, 10:43 AM by bitwiz.)

(08-17-2017, 10:06 AM)Narf Wrote: No, no kind of screenshot can indicate anything, just as your hardware doesn't really matter ... you're looking this from the wrong angle.

There's something blocking concurrent requests (if there are such) or time-outing (often a DNS lookup). Unless you're calling some other external service, I'd look at the DB config.

No external services. A little bit of jQuery is hosted locally on the server, minified, it just shows and hides a couple things with CSS.

Pages are mostly less than 10 input fields on forms that get stored in the database with some error checking involved, not super complicated.

DNS is not involved, the site doesn't communicate with external services. I've modified the hosts file on my PC to point to the server during development and the domain doesn't change, links don't leave the site.

I've commented out all the code in one of the controller's methods and I'm stepping through line by line to see if I can determine what affects the load times. Thanks for all the suggestions so far. I appreciate it!
Reply
#16

I've narrowed it down to a model that's encrypting and decrypting some fields stored in the database. Hmmm...
Reply
#17

(This post was last modified: 08-17-2017, 11:57 AM by bitwiz.)

I've been able to determine that it's a decryption problem. I'm using a phpFreaks Crypt library for reversible encryption and when the model decrypts the specific fields, it just sits. Dang. I think there was a reason I didn't originally use the built-in CI functions, perhaps a problem with that version. Now that I've updated to the latest, I think I'll try CI's built-in library again. I forgot I had done this.
Reply
#18

(This post was last modified: 08-17-2017, 12:29 PM by bitwiz.)

Woo! CI encryption library works! Site is nice and fast as I would expect! Thanks for all the suggestions! I really appreciate the CI community! And on top of it I learned a little about session locks.

Please don't mind my small public celebration... Thanks so much for the guidance!
Reply




Theme © iAndrew 2016 - Forum software by © MyBB